Content delivery networks (CDNs) have greatly improved the way content is transferred across data networks such as the Internet. A CDN accelerates the delivery of content by reducing the distance that content travels in order to reach a destination. To do so, the CDN strategically locates surrogate origin servers, also referred to as caching servers or edge servers, at various points-of-presence (POPs) that are geographically proximate to large numbers of content consumers and the CDN utilizes a traffic management system to route requests for content hosted by the CDN to the edge server that can optimally deliver the requested content to the content consumer. Determination of the optimal edge server may be based on geographic proximity to the content consumer as well as other factors such as load, capacity, and responsiveness of the edge servers. The optimal edge server delivers the requested content to the content consumer in a manner that is more efficient than when origin servers of the content publisher deliver the requested content. For example, a CDN may locate edge servers in Los Angeles, Dallas, and New York. These edge servers may cache content that is published by a particular content publisher with an origin server in Miami. When a content consumer in San Francisco submits a request for the published content, the CDN will deliver the content from the Los Angeles edge server on behalf of the content publisher as opposed to the much greater distance that would be required when delivering the content from the origin server in Miami. In this manner, the CDN reduces the latency, jitter, and amount of buffering that is experienced by the content consumer. The CDN also allows the content publisher to offload infrastructure, configuration, and maintenance costs while still having the ability to rapidly scale resources as needed. Content publishers can therefore devote more time to the creation of content and less time to the creation of an infrastructure that delivers the created content to the content consumers.
As a result of these and other benefits, many different CDNs are in operation today. Edgecast, Akamai, Limelight, and CDNetworks are some examples of operating CDNs that are responsible for the delivery of terabytes worth of content. FIG. 1 illustrates a representative infrastructure for some CDNs. As shown in FIG. 1, the infrastructure includes a distributed set of edge servers 110, traffic management servers 120, and an administrative server 130. The figure also illustrates the interactions that CDN customers including content publishers have with the CDN and interactions that content consumers or end users have with the CDN.
Each edge server of the set of edge servers 110 may represent a single physical machine or a cluster of machines. The cluster of machines may include a server farm for a geographically proximate set of physically separate machines or a set of virtual machines that execute over partitioned sets of resources of one or more physically separate machines. The set of edge servers 110 are distributed across different edge regions of the Internet to facilitate the “last mile” delivery of content. The edge servers run various processes that (1) manage what content is cached, (2) how content is cached, (3) how content is retrieved from the origin server when the content is not present in cache, (4) monitor server capacity (e.g., available processor cycles, available memory, available storage, etc.), (5) monitor network performance (e.g., latency, downed links, etc.), and (6) report statistical data on the delivered content. The set of edge servers 110 may provide the monitoring information to the traffic management servers 120 to facilitate the routing of content consumers to the optimal edge servers. The set of edge servers 110 may provide the statistical data to the administrative server 130 where the data is aggregated and processed to produce performance reports for the delivery of the customers' content.
The traffic management servers 120 route content consumers, and more specifically, content consumer issued requests for content to the one or more edge servers. Different CDN implementations utilize different traffic management schemes to achieve such routing to the optimal edge servers. Consequently, the traffic management servers 120 can include different combinations of Doman Name System (DNS) servers, load balancers, and routers performing Anycast or Border Gateway Protocol (BGP) routing. For example, some CDNs utilize the traffic management servers 120 to provide a two-tiered DNS routing scheme, wherein the first DNS tier resolves a DNS request to the CDN region (or POP) that is closest to the requesting content consumer and the second DNS tier resolves the DNS request to the optimal edge server in the closest CDN region. As another example, some CDNs use Anycast routing to identify the optimal edge server.
The administrative server 130 may include a central server of the CDN or a distributed set of interoperating servers that perform the configuration control and reporting functionality of the CDN. Content publishers register with the administrative server 130 in order to access services and functionality of the CDN. Accordingly, content publishers are also referred to as customers of the CDN. Once registered, customers can interface with the administrative server 130 to specify a configuration and view performance reports.
Specifying a configuration involves identifying the content that is to be delivered by the CDN, the amount of CDN resources to provision, the type of CDN resources to provision, the geographic regions where the CDN resources are to be provisioned, and the caching policies for the provisioned resources as some examples.
The performance reports are an essential feature of any CDN as they provide customers (i.e., content publishers) with insight as to how their configurations are performing across the CDN. The usefulness of these reports depends on their granularity and their freshness.
Granularity relates to the specificity of the performance reports. Less granular reports are useful in providing an overall view of the customer's configuration across the CDN. More granular reports are useful in providing a detailed view as to particular performance aspects of the customer's configuration.
Freshness relates to the temporal validity of the statistical data that is reported. In other words, freshness relates to the delay with which the statistical data is retrieved and processed before being reported to the customers. The closer to real-time the statistical data is reported, the sooner a customer or administrator can take action to address issues such as unexpected configuration errors, demand surges, network failures, or equipment failures.
However, existing reporting systems and methods are resource intensive and suffer from scalability issues. Specifically, many current systems and methods utilize a statistics server as a central hub for the aggregation and processing of statistical data from the edge servers 110 and for the distribution of the resulting performance reports to the customers. This is because the statistical data for a particular customer's configuration can be distributed across many edge servers and that statistical data must first be centralized before it can be processed to produce the performance reports. Therefore, the statistics server requires sufficient computational and memory/storage resources to (1) aggregate and store the statistical data from each of the edge servers in real-time, (2) process the aggregated statistical data to produce the performance reports for each customer of the CDN, and (3) disseminate the performance reports to the customers in an on-demand basis.
As the aggregated data becomes more granular or the real-time refresh rate increases, the amount of statistical data being passed from the edge servers 110 to the statistics server increases. This results in increased resource consumption at both the edge servers 110 and the statistics server. However, there is a greater impact on the statistics server than on the edge servers 110. For example, an increase in granularity that results in twice the amount of statistical data being reported from an edge server is magnified at the statistics server according to the number of edge servers that provide statistical data to the statistics server. Specifically, if each of four edge servers provides 1 MB of statistical data to the statistics server at periodic intervals, then the statistics server receives 4 MB of statistical data at each interval. If the granularity for the provided statistical data changes such that each edge server of the four edge servers reports 2 MB of data at each interval, then the statistics server receives 8 MB of data at each interval.
Moreover, the front-end demand for the presentation of the performance reports also consumes resources of the statistics server. As more customers request to view the performance reports, there is greater demand placed on the resources of the statistics server. When historic statistics are also reported, the statistics server is required to additionally store past statistical data in addition to the real-time statistical data. Consequently, the resources of the statistics server can be quickly over utilized.
While deploying a set of statistics servers can offload some of the load that would otherwise be placed on a single statistics server, such deployment does not ameliorate the large quantities of statistical data that is passed within the CDN. In fact, such deployment may exacerbate the situation when the statistical data has to be replicated to each statistics server in the set of statistics servers. Furthermore, the deployment does not ameliorate the overall amount of processing performed by the set of statistics servers and the deployment adds infrastructure costs for each newly deployed statistics server.
Accordingly, there is a need for improved systems and methods with which to perform granular real-time reporting within a distributed platform such as a CDN. Specifically, there is a need to reduce the amount of statistical data that is passed between the edge servers and the one or more statistics servers at a particular instance in time without degrading the ability (1) to report in real-time and (2) to report granular statistical data. There is also a need to reduce the memory, storage, and computational load on the one or more statistics servers such that the statistics servers can support reporting for larger numbers of customers, more granular statistical data, increased real-time refresh rates, and more edge servers without the need for additional resources. There is further a need to reduce the load on the one more statistics servers so that the servers can provide performance reports to a larger number of customers.